J. R. Casey Bralla
41 Mystery Rose Lane
West Grove, PA 19390
610-810-7716
The Mind-Body Dualism Problem
|
|
The NerdWorld Report J. R. Casey Bralla 41 Mystery Rose Lane West Grove, PA 19390 610-810-7716
|
Technology, Religion, Politics
and The Mind-Body Dualism Problem |
JRC-65 Computer
Tech Info
Essays
Site Hosted by
Vorlon Information Technologies
.png)
Entire site Copyright © 2024 by J. R. Casey Bralla
(except for obvious external works).
All rights reserved.
NOTE: If you link to this site,
or otherwise find it useful,
please send a brief note to the author.
.png)
For reasons known only to my psychiatrist (and he's not talking!), I decided to undertake the arduous task of loading Gentoo Linux on my Eee PC netbook (Model 1015-PEM-PU). This ended up requiring several attempts, but I was eventually successful and have a sparkling, quick, easily carried netbook computer. This is a record of how I did it, as well as some of the critical files I needed to make it work.
Why Gentoo?
I've been a longtime fan of Gentoo (and now Funtoo). When I got a netbook at Christmas 2010, I tried to load Gentoo on it, but got flummoxed by the hardware selection and the long time needed to compile all the software. In frustration, I dumped Gentoo in favor of my second favorite distro, Debian. I was able to load Debian without any trouble, and ran Debian Unstable for quite some time. Still, in the back of my mind, Gentoo called to me. For maximum performance from minimal hardware, you can't beat Gentoo. I wanted to minimize the memory and processor overhead so that the little 2-core Atom CPU could work its blessed little heart out as efficiently as possible. Also, I wanted to minimize the memory footprint of the system, since the Eee maxes out at 2 GBytes of RAM, which is about half the "normal" amount needed these days. The best way to maximize the performance of my Eee, I knew, was to custom compile all the software for the Atom processor, and to build a kernel that loaded the absolute minimum number of modules. It took me a couple of tries over several months to get this right. What I am about to describe is the culmination of those efforts.
Not For the Faint of Heart
Unlike other Linux distributions, installing Gentoo is not a simple, 1-hour job. Since every program has to be compiled from source, you need to figure the entire process of loading Gentoo on the Eee may take 72 hours or more. (This is in addition to the times the compilation crashes and stops at 3:00 AM and you don't find and debug the problem until 8:00 PM the next day.) In fact, I prefer to recompile ALL the software on the machine SEVERAL times during the installation process to ensure I've got all the software optimized properly for my hardware.
If you are one of those people who feels that "instant gratification isn't fast enough", you're looking for lots of frustration with Gentoo on the Atom. If however, you're willing to make a strong, concerted effort, you will be rewarded with a very nimble, optimized netbook.
You may be asking yourself, is it worth it to go to all this trouble just to get a slight (theoretical) improvement in performance? The answer is "who knows?" If you're suffering from OCD like I am, it's almost a necessity. However, I found that Debian on the Eee ran very well. In truth, there probably is no real reason to go to all this trouble with Gentoo. Nonetheless....
By the way, if you want to see how I loaded Debian on the Eee, with a bit of an Eee review thrown in, please see my previous blog entry: Debian on an Eee PC
The Process - Summary
So here is how it's done:
OK, that's the 20,000 foot overview. Now let's get into the details.
The Detailed Process - Step 1: Detect Hardware & Required Modules
Our first problem is to determine exactly what hardware is on the Eee so we can select the proper kernel modules. It's a surprisingly difficult problem to determine what hardware your computer has, and to find the correct modules to build to drive it all. You could simply use the "genkernel" technique and let Gentoo pick the modules it needs, but I find this too "un-optimized" for me. It tends to load many modules that will never be used (like parallel port drivers) and it also adds lots of time to the kernel compilation, since EVERY darn module needs to be built whether it is needed or not. I want a monolithic kernel with all the correct modules compiled in - and none of the unneeded modules present. (My Eee has the maximum possible 2 GBytes of RAM, which is way too small for me. I want to minimize the memory footprint of the kernel to leave more room for applications.)
To determine your hardware, you can run utilities like lspci and hwinfo. Both of these are excellent at getting "close" to the correct modules, but even so, I always have trouble finding the correct settings when compiling the kernel based on the information these utilities provide. For example there are several minor revisions to the Broadcom B43 wireless network module which work on slightly different versions of the Broadcom chip. hwinfo can't always reliably tell you which of the several modules is the correct one to build. The secret solution to this problem is to run a live distro that has excellent hardware detection, and see what modules actually get loaded. This will almost always include some modules you do not need, but it will absolutely tell you which of several similar modules you do need.
I used Knoppix for this task. I booted the Eee with a Knoppix thumb drive and then printed the output of lsmod. Some of the modules, like the ones for parallel printer drivers and serial ports, can be ignored since the Eee has neither of these interfaces. However, I paid extra attention to SATA, graphics, wireless, ethernet, and sound hardware drivers. Later, when I was running make menuconfig to select the kernel modules, I would use this list to ensure I had the correct modules.
Special Tip to Find Correct Modules
Here's a special tip on how to select the proper module that I discovered only recently:
Press the "/" key while in make menuconfig and then enter the name of the module (or info about the hardware) in the search window. The kernel system will find all the references to that string and clues to where you can find the settings to activate it.
Often you will find that module you want will not be visible in the configuration menu since there is another item which has not been selected (or sometimes, several items which have not been selected). In those cases, you have to closely examine the dependencies listed in the returned text and then make several adjustments to get all the required modules built. This can sometimes be a long trial and error process.
By the way, here are the critical networking kernel modules for the Eee:
The Detailed Process - Step 2: Prepare the Disks
Once you have the list of installed modules, you can boot to the Gentoo stage 3 disk, or to the Funtoo "system rescue" disk and proceed with the normal Gentoo/Funtoo process of formatting the hard drive and installing the basic system.
Funtoo recommends that you use the new version of "grub" (grub2) to boot the disk. Grub2 uses a very different configuration scheme that can be confusing until you become familiar with it. I liked the grub2 technique once I became familiar with it. However, I did not like the way grub2 wanted a unique type of partition that cfdisk could not create. [UPDATE from 2024: This is the UEFI system, which still confuses me a little] I therefore elected to create partitions in the normal way with cfdisk, and simply have grub2 use the Master Boot Record (MBR) just the way the old grub used to.
The configuration files for grub2 are way too complex for mere mortals to create and edit. Luckily Funtoo provides a very nice program (boot-update) which reads a very simple configuration file (/etc/boot.conf) and automatically creates the terrifying grub2 configuration file. In fact, this process was even better than I had thought since it automatically boots the most recent kernel if you happened to keep your old kernels around for safety sake.
You have to decide what type of file system you want to use. I used to be a ReiserFS file system enthusiast, but decided that Hans Reiser won't be doing too many more updates from prison after he was convicted of murdering his wife. (What a wacko he turned out to be!) Lately, I've been using ext4 without any trouble at all.
The Detailed Process - Step 3: Set the USE Flags & CXFLAGS
USE flags are one of the coolest parts of the Gentoo system. They allow an almost unprecedented control over what gets built in to the system. However, I have often noted that setting too many USE flags too early in the installation process tends to cause trouble with circular dependencies. Each USE flag tends to pull in at least one additional package, and I have found that it is better to get a fully function simple system first. Later, we will add USE flags will-nilly, but for now, the K.I.S.S. principle seems appropriate. This means that for the initial stages of building a Gentoo system, the USE flags are kept to an absolute minimum, which in my case meant they were completely blank (ie: no USE flags at all).
The other critical part of Gentoo is the CXFLAGS settings. These tell the compiler what type of CPU architecture your system is using so that the programs can be optimized for that particular system. In the olden days, I used to scour the internet for advice on how to set these. Luckily, for modern versions of the gcc compiler, all you have to do is say "auto" and the system will do the heavy lifting for you. If gcc knows anything about your CPU (and it does!), then the compiler flags will be automatically optimized for your CPU. (The traditional way is to explicitly specify the CPU type. In my case, the Eee use the type "Atom".) Of course, you can still add other optimizations such as "O3" to optimize for speed or "O2" to optimize for small memory footprint, or any of a dozen others. I prefer to keep things pretty simple, so my CXFLAGS line is:
If you like, you can also elect to build the "unstable" branch of Gentoo. For my desktop system, I love living on the bleeding edge of stability. I therefore spend a lot of time upgrading and compiling software. On my little Atom, however, I didn't want to be constantly recompiling what already works, so elected to stay in the land of stability. I therefore set the variable:
(Yeah. Even though the Eee has an Intel Atom processor, you tell Gentoo you're using and AMD-style 64-bit architecture. Why? Beats me!) Note that I have elected to build the system as 64-bits. Theoretically, a 32-bit system would require less memory since the system only has to maintain 32-bit registers. However, a 64-bit system is also able to use 64-bit instructions which are theoretically faster. Is a 64-bit system truly better? Beats the heck outta me! Use the one that makes you feel better.
The Detailed Process - Step 4: Compile the Kernel (and boot loader)
You get a very wide range of possible Linux kernels with Gentoo, and a smaller list if you like Funtoo. If you are a purist, you can compile the official "plain vanilla" Linux kernel, which is considered an "excellent" choice for Funtoo. In fact, if you are adventurous, you can compile the testing kernel directly from Linus Torvalds' git repository. I recommend that you select "gentoo-sources" if you are running Gentoo, or "vanilla-sources" if you are running Funtoo. Why? Heck, I don't know. These both seem to work for me and the Gentoo-sources supposedly is "optimized" in some mysterious way.
I found a couple of "gotchas" with the kernel. First, the Eee uses the Broadcom 4377 wireless chip which requires firmware to be downloaded separately. (The easiest way is to "emerge linux-firwmare", which will install these firmware files, and many others.) The kernel then needs to be told where to look for the firmware, since it's not smart enough to find it on its own. Be sure to set the "Include in-kernel firmware blobs", and to clear the settings that will prevent the binary blob from being loaded (I think this is required, but am not sure). Then set the Firmware blob root directory (which is usually /lib/firmware, and then explicitly name the firmware modules to load. Therefore, these three entries read:
I also edited the /etc/boot.conf file to remove the entire menu section for the genkernel system, since we're only going to have a monolithic kernel.
Once we have set all the configuration options, we compile the kernel with the commands
On the Atom, this will take about a half hour or more.
I used a custom-written shell script to compile the kernel (a copy is in the archive. It's called "newkernel").
This script renames the newly compiled kernel with the current date so you can easily keep multiple kernels.
The new grub2 boot system will automatically take the most current kernel as the default, however.
The Detailed Process - Step 5: Re-compile the World and Reboot
Now that we've got a good kernel and have established all the proper CXFLAGS, I like to completely recompile the entire installed system using all these settings. I'm actually not totally certain that this step is necessary, but it seems to fit into my OCD, so I do it anyway.
The good thing about this step is that it rebuilds all the libraries so that they are fully compatible with the Atom processor. Remember that we haven't set the final USE flags, so the system is still relatively small. Essentially, all we have installed at this point is the most basic command line Linux system. That means the recompile time is only a few hours instead of a few days.
So go ahead and find a good movie to watch, or go to bed early. Run
By the way, I almost always set the "--keep-going" option when compiling a long list of programs. This prevents the system from stopping the whole process if a single package has a problem. Since this is going to take hours overnight to run, the last thing you want to find on the screen the next morning is an error message from the second package to be compiled.
The Detailed Process - Step 6: Emerge Wireless Drivers
At this point, you've got a working Linux system that has a working ethernet port, but not a working wireless system. If you desire, you may at this point emerge all the appropriate wireless utilities. These include
It also a good time to load any normal system utilities you might like to use. I emerged
The Detailed Process - Step 7: Emerge Xorg & Your Favorite Desktop Environment
You almost certainly will want to run a graphical desktop. That means you have to install xorg-x11. This is pretty simple, simply enter:
The xinit program allows you to start the desktop with "startx". Most people will probably start their desktops automatically at boot time. I prefer to boot to text screen, and then start the desktop GUI manually. This means I also have to delete the program /usr/bin/kdm to prevent the system from starting the graphical log-in page.
Once this compiles, you can then compile your favorite desktop environment. I prefer KDE, even though it's a bloated hog. This I do with the command
You may want to close up the house and take your vacation at the beach while this compiles, since it will take the better part of a full day (if there are no errors).
NOTE: It is very likely that there will be conflicts, circular dependencies, and other problems trying to compile this many programs. You will undoubtedly have a lot of trouble-shooting to do here.
The Detailed Process - Step 8: Set the USE Flags
We've got a wonderful graphical Linux system running. Everything works great, although there are some features you're missing. Now let's set all the USE flags to reflect our final configuration.
USE Flags, as any Gentoo user will tell you, can be trouble when you are making major changes to the system. Major changes in the USE flags tend to cause all kinds of weird circular dependencies and other miscellaneous nastiness. I think you will be OK to simply adopt all the USE flags I've included in one swell foop, but you may find that you have to add them in a few at a time.
The Detailed Process - Step 9: Update Everything and & Incorporate all the USE Flags
At this point, you need to do another a very long compile. In order to actually take advantage of all those USE flags and add functionality to your system, you need to recompile everything so that they properly reflect your flags. The way to do this is:
This may take a full day or more, depending on how many USE flags you've set. It also will probably trigger all kinds of weird errors about circular dependencies and incompatible package versions. My advice to you here is "Good Luck!". This is what separates the Nerds from the Nerdlings in Gentoo.
Update: I wrote this basic document over a year ago, then abandoned Gentoo in disgust when I kept on getting dependency errors during normal updates and things would not compile. I wiped my disk of Gentoo and went back to my old trusty friend, Debian.
I even had discussions with a famous Gentoo developer (He's been quoted in Linux Weekly News) that I know casually from our local Linux user Group (PLUG) about my Gentoo troubles. He believed that my troubles were unique, and did not reflect the normal Gentoo experience. Maybe so, all I know is they aggravated the heck outta me, and I dropped Gentoo with disgust.
But Gentoo kept calling me! Debian got boring. Things just worked! I didn't have any problems to solve, and I knew my computer would run faster if I could have custom compiled programs. Also, Debian rarely had updated software to install. It's the "existential pleasures of computer engineering" that I like. Once the darn thing actually works, I lose interest.
So I succumbed, wiped my Debian disk, and started with Funtoo. What follows is my diary of installation, complete with warts, difficulties, some minor cussing, and (hopefully) glorious triumph at the end.
Day 1. Sunday August 12.
I created a USB disk with SystemRescue, the preferred starting system for Funtoo. I normally use "UNetbootin" to create bootable thumb drives, but the SystemRescue site says UNetbootin doesn't work with SystemRescue. Instead I followed their instructions, which includes running a provided batch file which automatically creates the bootable USB disk. I only had one problem; the documentation doesn't tell you that the thumb drive has to be completely clean, without any file system at all. It errored out on me several times because my thumb drive was formatted with VFAT, and therefore had "zero" bytes available. FDisking the thumb drive to remove the file system did the trick.
Creating the file systems on my Asus hard disk was a breeze, since I've done it dozens (hundreds?) of times on numerous computers. I also discovered that Debian had wasted a few megabytes of my disk in its default system. My manually created file structure used every byte on the disk.
I loaded the basic Gentoo system, set my basic flags in /etc/make.conf, and everything seemed just fine. I decided to throw caution to the wind and build the "current" version (previously known as "unstable"). I set the term
The Funtoo documentation describes this as "current".
It remains to be seen if it also should be described as "broken" Compiling the kernel gave me a few troubles because I accidentally forgot to enable the "ext4" file system module.
Later, I had some difficulty finding out how to compile the "atl1c" module for the Eee's ethernet chip.
But after a few tries, everything worked.
I re-emerged the entire system overnight. (It took about 6 hours).
Day 2. Monday August 13
The computer was waiting patiently for me the next morning, the recompile having completed without difficulty while I slept.
I rebooted into the newly recompiled, pristine system.
The next step is to compile Xorg-X11.
The Eee uses the Intel i915 graphics chip, which seems to be well-supported in Linux.
I told Gentoo what type of chip I had with the line:
I then tried to compile xorg-x11 first thing in the morning, but got an error which said:
* Error: circular dependencies:
(media-libs/mesa-8.1_rc1_pre20120724::gentoo, ebuild scheduled for merge) depends on
(x11-base/xorg-server-1.12.3::gentoo, ebuild scheduled for merge) (buildtime)
(media-libs/mesa-8.1_rc1_pre20120724::gentoo, ebuild scheduled for merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- media-libs/mesa-8.1_rc1_pre20120724 (Change USE: -xorg)
Note that this change can be reverted, once the package has been installed.
The following USE changes are necessary to proceed:
#required by media-libs/mesa-8.1_rc1_pre20120724[xorg], required by x11-base/xorg-server-1.12.3[-minimal], required by x11-drivers/xf86-input-mouse-1.8.1, required by x11-base/xorg-drivers-1.12[input_devices_mouse]
>=x11-libs/libdrm-2.4.38 libkms
Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT).
Maybe it was because the hour was early, but this message made almost no sense to me.
Later, that afternoon, I realized that the mesa library was messing up, so I simply emerged mesa with the temporary USE flag of "-xorg".
This forced the compilation of 31 packages, including the offending "mesa".
Afterwards, I was able to retry emerging xorg-x11, which worked without any problems and compiled the required 138 packages for the X-window system.
Oops! I just realized I made my swap partition is too small.
It's smaller than my 2 GBytes of RAM, so it will not hold all the system memory during hibernation.
I therefore resized the partitions with gparted on SystemRescue so I didn't have to start over from scratch.
Day 2. Tuesday August 14
Xorg-X11 seems to have compiled correctly overnight.
However, X won't start, giving the error
This is probably a configuration problem, which I will deal with later.
In the meantime, I'll try to emerge KDE with the command:
Unfortunately, Gentoo complained about missing USE variables (because I haven't set any yet).
I then set the required variable, tried the emerge command again, only to be told I needed another USE variable set.
Eventually, I got all the required USE flags set.
Here's the final list of what had to be set in order to build KDE (in the order Gentoo demanded them).
Once these were set, I started the KDE compilation (all 420 packages!), and went off to work for the day.
Well, when I got home, I found that the emerge had stopped, due to some strange and unknown problem, and there were still 259 packages still to be compiled.
I restarted the emerge, and let it compile overnight.
Day 3. Wednesday August 15
Awaking the next morning, I found that the compilation had failed again at the package "kmix".
Here is the very unhelpful error message I was left with:
What caused the error? Beats me!
I simply restarted the emerge (3rd time) and let it run while I went to work.
Emerge compiled the 155 remaining packages in KDE while I was gone.
Bazinga! When I got home, KDE had completely compiled.
Now to try to debug Xorg-x11.
Once again, trying "startx" resulted in an error.
I checked the logs at /var/log/Xorg.0.log.
It showed that none of the possible video drivers had loaded.
I further checked to see if the Intel video driver had compiled, by typing
which listed all the X drivers.
Sure enough, xf86-video-intel had not compiled.
Hmmm.. Figuring I had made a typo somewhere, I double-checked the VIDEO_CARDS entry in /etc/make.conf, and sure enough, I had type "Intel" with a capital "I".
I edited it to all lower case, and then tried
to see if this would trigger the compilation of this package.
Unfortunately, it didn't work, so I manually compiled it with
This compiled 4 packages, including my desired Intel driver for my i915 chip.
This time, startx worked... almost.
The x-window system started, then failed because the "twm" window manager was not found.
Obviously, X did not know to start KDE.
The fix was to create the file .xinitrc in my home directory, and put the line "startkde" as the only entry.
With this, KDE started!
Now it is time to do some more basic compilation.
I started with
to have KDE pull in the excellent networkmanager package.
Just before bedtime, I resync'd portage and then emerged porthole, then did a universal update.
Day 4. Thursday August 16
This ran overnight, but crapped out on the 50th of 55 packages when foomatic-filters announced it needed a2ps, enscript, mpage, or CUPS' textops in order to compile.
In the meantime, I debugged the lack of wireless and realized I had screwed up the kernel settings for firmware.
I had not specified the location of the firmware files properly.
Also, instead of copying an old file of the firmware, I simply installed the linux-firmware package.
This has firmware for tons of stuff I don't use, but only the one specified in the kernel configuration will actually get loaded.
(The instructions in the main section of this document have been corrected for these errors.)
After recompiling the kernel and rebooting, wlan0 appears in my list of network devices!
I'm off to work, so before I go, I emerged a2ps and restarted the deep update I had started the night before.
By the time I got home, everything had compiled, but I discovered that a new kernel version had appeared in the Gentoo repositories.
(BTW, be sure to set the "symlink" USE flag to make sure /usr/src/linux points to the correct, current version of the kernel source.)
So I compiled the new kernel and booted into the new system.
However, when I tried to run the KDE networkmanager program, the application would crash with a segfault.
I suspected that it was fighting with the dhcp assignment, since I had dhcpcd running.
I stopped dhcpcd, but that didn't stop the crashing.
Then I discovered that I needed to start /etc/init.d/NetworkManager (note the unusual capitalization of the name).
Once that was started, I could use Networkmanager to control all my connections, including the wireless.
I was in business!
Then I used the USE flag editor UFED to set a bunch of flags to add a bunch multimedia capability and other things I thought were good to have. I then ran
and let it run overnight.
Day 5. Friday August 17
The next morning, I found that 50 of the packages had compiled, then the emerge stopped because "libimobiledevice" had failed.
I re-sync'd and retried the update command again.
Alas, it failed again.
I presume that my "ipod" USE flag is forcing this package to be built.
I therefore deleted that USE flag and tried again.
Still no good. Time to start paring back those USE flags.
This time I deleted the "ios" flag, which enables all Apple devices.
That did the trick!
Emerge was off and running, without trying to compile libimobiledevice!
OK, now to add some more applications, such as firefox, adobe-flash, foomatic-db, and kmail.
Ahhh, but I need to change some more USE flags. Firefox requires "apng", and adobe-flash requires a license allowance setting.
I also tried to emerge kmail, which demanded "semantic-desktop" be set.
Once I changed the USE flags, I realized I had to (potentially) update a bunch of previously emerged packages to use the new USE flags, so I combined the update command with the emerge command with
and went to bed.
Day 6. Saturday August 17
The packages (all 69 of them) were still compiling when I got up.
Day 7. Wednesday August 22
I had to go out of town for a while, and got on to some other projects.
Now I'm back.
I'm having trouble with the hibernation and sleep systems.
I can make the system go to sleep manually using the KDE sleep menu command, but closing the lid does not do it automatically, despite my settings in the KDE power section.
Also, I can tell the system to hibernate, but it won't resume (it just boots as if it were shut down normally).
A little digging in the Gentoo Power Management Guide suggests I left a few critical ACPI items unchecked.
Also, it recommends the ACPI USE flag be set (which it has been).
It also suggests loading "laptop-mode-tools", which I had not done.
So I recompiled the kernel, emerged laptop-mode-tools (compiling 7 packages) and we'll see what happens.
Rats! Hibernation gets triggered when the lid is closed as expected, but does not restore.
Sleep works, however.
A little more thinking, and I decided to explicitly set the "resume from hibernation" setting in the kernel.
The docs seem to indicate that the kernel would always look to the first swap partition, but apparently that is not true.
Adding "/dev/sda2" (my swap partition) to this parameter made the restore from hibernation work.
Day 8. Thursday August 23
Everything works! I had to make a tweek to a KDE file to prevent the Konqueror and Dolphin icons from being on the launchpad all the time.
(You can delete them, but they annoyingly reappear every time you restart KDE.)
The secret was to edit the file ~/.kde4/share/config/plasma-desktop-appletsrc and delete the lines referring to "preferred=".
Now it's time to make the system a little more multi-media friendly.
I'll start messing with some USE flags. Here's what I set:
This caused 2 packages to be installed and a single package to be rebuilt.
Day 9. Saturday August 25
Now its time to set some USE flags and rebuild as necessary.
I used the list at http://www.gentoo.org/dyn/use-index.xml to find the flags I wanted to set.
I then set the following USE flags:
Updating the entire world with these USE changes was surprisingly easy, so I threw caution to the wind and tried to enable Apple's IOS integration so my Eee could connect to my iPhone.
I set the "ios" flag and tried it again.
(Last time, you may remember, this failed when libimobiledevice would not compile.)
Unfortunately, the same thing happened again, so I cleared the "ios" flag and instead set the "ipod" flag.
This worked, but only because it did not force the compilation of any packages.
Ooops.
I realized that I had not compiled modules for the webcam.
The Eee needs uvcvideo in the kernel, so a quick recompile of the kernel enabled the camera.
Also, I downloaded the "static" version of skype, and everything worked.
(I did have to change the mixer to enable the "capture" setting first in order to get sound.)
The last thing I wanted to do was disable (or reduce the sensitivity) of the touchpad.
The Eee does not have a synaptics touchpad, so the normal synaptics utilities won't work.
I tried installing synaptics drivers, but that didn't work.
That darn touchpad was so sensitive that every time I typed on the keyboard, I sent the cursor sailing.
So I did a little research, but couldn't find anything about a non-synaptics pad.
The Eee has an "ETPS/2 Elantech" touchpad.
A little googling showed that there is a Linux driver for it, and it's been available in the kernel for some time!
Back to recompiling the kernel, finding the correct driver (in plain sight under the mouse drivers!), and recompiling.
This made the touchpad a "synaptics-compatible" for the purposes of Linux.
I also had to add some info to /etc/make.conf.
I had been a little surprised that I didn't have to add a line for Input Devices in this file.
With the touchpad, I had to tell Funtoo a touchpad was there, or it would never pull in the touchpad module for the X window system.
I therefore added this line to /etc/make.conf:
I re-emerged the world, and behold!, I had a controllable touchpad.
Emerging the package "synaptiks" gave me an entire 3-page setting area in the KDE "systems setting" program.
I also emerge "ktouchpadenabler", which allows the Eee's touchpad controller key (Fn-F3) to turn on and off the touchpad completely. It works!
Day 10. Sunday August 26
Since I had missed the proper touchpad driver, and discovered that I had allowed some unneeded drivers to be compiled, I decided to take a thorough deep-dive into the kernel to be sure I wasn't building any other unwanted modules.
As you may remember, one of my goals was to have a monolithic kernel that contained only the parts I needed.
I found several other modules that I didn't need and recompiled the kernel.
The kernel file shrunk down to 4.4 MBytes.
My original kernel had been 4.7 MBytes. Whoo Hoo!
I had saved 300 KBytes of RAM by carefully compiling a monolithic kernel, just for my hardware.
(Kind of like the old Newlywed Game, a "grand prize chosen especially for me!")
Conclusion
So that makes Gentoo on the Asus Eee.
It's not a task for the faint of heart, but it can be done, and it yields a fine Linux system.
Is it worth the effort? Probably not, unless you enjoy solving computer problems.
Funtoo/Gentoo is an acquired taste; more of a badge of honor than a simple Linux distribution.
But like the ugliest puppy in the litter, it's all mine and I love it!
VIDEO_CARDS="intel"
USE="-xorg" emerge mesa
Fatal Error:
No Screens Found
emerge kde-meta --keep-going
opengl
dbus
qt3support
cairo
X
webkit
svg
declarative
sql
mng
minizip
policykit
consolekit
qt4
make[2]: Leaving directory `/var/tmp/portage/kde-base/kmix-4.9.0/work/kmix-4.9.0_build'
/usr/bin/cmake -E cmake_progress_report /var/tmp/portage/kde-base/kmix-4.9.0/work/kmix-4.9.0_build/CMakeFiles 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
[ 93%] Built target kdeinit_kmix
make[1]: Leaving directory `/var/tmp/portage/kde-base/kmix-4.9.0/work/kmix-4.9.0_build'
make: *** [all] Error 2
* ERROR: kde-base/kmix-4.9.0 failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=kde-base/kmix-4.9.0'`,
* the complete build log and the output of `emerge -pqv '=kde-base/kmix-4.9.0'`.
* The complete build log is located at '/var/tmp/portage/kde-base/kmix-4.9.0/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/kde-base/kmix-4.9.0/temp/environment'.
* Working directory: '/var/tmp/portage/kde-base/kmix-4.9.0/work/kmix-4.9.0_build'
* S: '/var/tmp/portage/kde-base/kmix-4.9.0/work/kmix-4.9.0'
>>> Failed to emerge kde-base/kmix-4.9.0, Log file:
>>> '/var/tmp/portage/kde-base/kmix-4.9.0/temp/build.log'
emerge --search xf86
emerge xorg-x11 --newuse
emerge xf86-video-intel
emerge networkmanagement
emerge porthole &&
emerge --deep --newuse --keep-going -u world
emerge a2ps &&
emerge --deep --newuse --keep-going -u world
emerge --deep --newuse --keep-going -u world
ACCEPT_LICENSE="*"
emerge --deep --newuse --keep-going -u world firefox adobe-flash kmail
avformat
mp4
amr
cpudetection
mjpeg
google-gadgets
eigen
archive
sftp
desktopglobe
id3tag
nfsv3
nfsv4
nfsv41
additions
extensions
INPUT_DEVICES="evdev keyboard mouse synaptics"